%\begin{further}
%\setcounter{section}{0}
\subsection{Introducció}

Aquest era un projecte ambiciós en el seu plantejament, que dona lloc a un gran ventall de possibilitats d'expansió futura. En aquest apartat es comenten algunes d'aquestes possibles millores futures, les que resulten més importants i també les que són més atractives i llamineres.

\paragraph{}
Per assolir resultats en un temps raonable no s'ha realitzat tot el que vam idear, així, en l'acord que representen els objectius del projecte, es van deixar de banda algunes funcionalitats.

\subsection{Expansió de les funcionalitats de la façana}

Degut a restriccions de temps la façana permet una interacció limitada amb els usuaris, i això seria un bon punt per on millorar el projecte.

\paragraph{}
Per assolir això hi ha un gran ventall de possibilitats, però jo proposaria integrar la biblioteca estesa de mapsforge a la façana, i redefinir funcions que puguin resultar útils als usuaris de SL4A.

\paragraph{}
En aquest cas, un petit estudi al respecte seria necessari.

\subsection{Integració ``oficial'' a el projecte mapsforge}

Tal i com he explicat en l'apartat de \hyperlink{espec-treball-comunitari}{treball en comunitat} els mòduls de tractament de kml i gml han estat desenvolupats sobre les biblioteques mapsforge, però aquesta modificació encara ha de ser aprovada per la comunitat i integrada al projecte mapsforge, per això es possible que encara s'hagi de desenvolupar i adaptar a alguns requisits que puguin anar sorgint segons la comunitat revisi el codi. 

\paragraph{}
Actualment és una modificació funcional de mapsforge i ja es accessible a la comunitat de software lliure per a qui la pugui voler emprar, però l'objectiu sempre havia estat que no es tractés d'un ``fork'' del projecte sinó d'integrar les modificacions a ell. 

\paragraph{}
Però per això és necessari un procés relativament lent de revisió del codi que he fet per adaptar-lo a la versió actual de l'API d'Overlays (ja que els membres de la comunitat ho van plantejar així).

Seria desitjable que aquesta tasca, o almenys les parts més importants, la realitzes jo mateix. Per tant, tinc pensat de continuar-hi treballant en la mesura que sigui em possible. 

\subsection[Utilitzar Python]{Millora de les interfícies i les funcionalitats aprofitant Python}

Al proporcionar una façana per a SL4A algunes de les funcionalitats de les biblioteques de mapes han estat reduïdes, ja que s'ha hagut de crear una abstracció a molt alt nivell de les funcionalitats.

\paragraph{}
Això no vol dir, però que no es pugui aprofitar el potencial de Python per incrementar les funcionalitats de la biblioteca i també per millorar-ne la interfície.

\paragraph{}
Una interessant proposta podria ser modificar i tractar els mapes offline amb eines de Python a nivell de fitxer kml/gml o osm i mostrar-los posteriorment.

\subsection[Visualització avançada de KML/GML]{Expansió de les capacitats del modul de KML GML per visualitzacions avançades}

Actualment, i degut a limitacions, tant de temps per part meva com degut al propi disseny de les biblioteques de mapsforge per renderitzar mapes, no s'estan aprofitant al 100\% les capacitats dels formats kml i gml.

\paragraph{}
Per posar un exemple, kml permet representacions en 3D de estructures (el programa Google earth les permet visualitzar)

\paragraph{}
A continuació llisto les capacitats més interessants que se'm acudeixen per poder suportar en un futur:

\begin{itemize}
\item Mostrar estructures tridimensionals.
\item Permetre personalitzacions d'estil configurades en els fitxers (actualment les personalitzacions s'apliquen a nivell de programa i les que es puguin definir al fitxer són ignorades).
\end{itemize}

\subsection{Contribució a OpenStreetMap}

Una funcionalitat molt interessant que es va observar del projecte OsmAnd, i que no estava plantejada als objectius del projecte, era la d'aportar noves dades a la comunitat d'OpenStreetMap fent servir l'aplicació generada, o proporcionar mètodes encarats a tal objectiu a la mateixa biblioteca de mapes.

\paragraph{}
Actualment mapsforge no proporciona aquesta funcionalitat, i tot i que es tracta d'una característica complexa i que cal estudiar amb deteniment, no veig cap motiu pel qual no es podria implementar.

\paragraph{}
Els beneficis de tal funcionalitat són evidents, ja que permetria la actualització/correcció o simplement generació de noves dades sobre els mapes al mateix lloc on es troben, i no tan sols de punts d'interès sinó també de polígons, etc. I tot això independentment de si es disposa de connexió de xarxa al moment.

\paragraph{}
Certament aquesta seria una molt bona millora a proporcionar, tant si es planteja com una millora a nivell d'aplicació, com a nivell de biblioteca (ambdós podrien tenir sentit si es plantegen adequadament).

\subsection{Optimització de recursos}

Mapsforge es una biblioteca pensada per a ser executada en la plataforma Android, cosa que comporta certes limitacions de memòria disponible i capacitat de càlcul. Això fa que la eficiència sigui bastant rellevant per a la comunitat de mapsforge a l'hora de fer les coses.

\paragraph{}
Tot i així la gestió dels Overlays que fa no és perfecte i te certes limitacions a la escalabilitat.

\paragraph{}
Prova d'això és la modificació de la API d'Overlays que els mateixos desenvolupadors van fer per intentar solucionar-ho.

\paragraph{}
Si a això hi afegim la carrega addicional a parsejar i gestionar els fitxers KML (que tot i ser molt menor no és negligible quan parlem en plataformes limitades com Android), i el fet que ara per ara no hi hagi cap control o limitació sobre els possibles fitxers que els usuaris carregaran, provoca que es pugui donar la situació que al carregar determinats fitxers l'aplicació que faci servir les biblioteques sigui pràcticament inusable.

\paragraph{}
Tota aquesta casuística pot ser controlada i gestionada per les aplicacions que utilitzin la biblioteca, però malgrat això, hi ha certs aspectes que seria bo de millorar a la banda de la biblioteca per facilitar als usuaris aquesta gestió dels recursos.

%\end{further}
